Framelets—small is beautiful

The contribution introduces the notion of framelets. They are essentially small frameworks. Thus framelets can be easily understood and modified. As framelets are not aimed at complex application domains, they can also be assembled without the problems associated with the combination of large frameworks. Our first experiences with framelets demonstrate that these architectural building blocks allow the integration of framework technology into legacy applications. Furthermore, framelets might form a suitable means for structuring software architectures. 1 Frameworks and legacy applications Conventional wisdom implies that legacy applications and framework technology do not match well. Framework experts usually advise the development of a domain-specific architecture for the domain at hand. The legacy application would have to be replaced by the adapted framework. Most companies are not willing to pursue such a radical approach, which renders the investments into legacy applications worthless. Furthermore, the development of a complex framework from scratch represents a formidable risk. The brilliant architects who would be able to design domain-specific frameworks are often not available. This situation forms the starting point of our considerations, i.e., how framework technology can be harnessed in the realm of legacy applications. The legacy system at hand is a client/server application of a bank. Our approach is straight-forward: Taking a look at the overall conventional system architecture and then at the underlying source code reveals that some quite small aspects of the system are implemented numerous times again and again in a similar way. For example, the legacy application relies on remote procedure calls (RPCs) implemented in C. The code associated with a particular RPC implies tedious programming work, in particular handling the parameter value transfer for each RPC. For example, the return parameter types are C-style arrays, which have to be properly processed. The RPCs are too diverse to come up with a simple reusable procedure/function. Instead we found that a small framework is the solution in order to automate the calling of remote procedures. The hot spot of the RPC framelet is the processing of parameters. Another example of reimplemented code can be found at the client side of the legacy system. Most dialogs provide one or more list boxes (a.k.a. grid controls) together with buttons to add items to the list box, and to modify and remove them. Thus these GUI elements and their interactions have to be implemented again and again. The associated programming task is another typical example of a piece of programming work that can easily be packaged into a small self-contained framework. The hot spot of the so-called list box framelet is the dialog, which displays an item. Figure 1 shows a sample specialization of the list box framework. The dialog on the left-hand side consists only of the framework’s GUI and the button labeled Close. The arrows in Figure 1 indicate the interactions between the framework components.